CCN architectures have been disclosed for instance in documents US20090288163, US20090287835 and US20090285209.
In a Content Centric Network, each content delivered in the network has a unique structured name. The nodes of the network declare their interest to some content by sending an Interest packet with the name of the desired content to other nodes of the network. Upon reception of an Interest packet, a first CCN node determines whether the content satisfying the Interest packet is available. If so, the corresponding content is sent to the Interest packet requesting node. Otherwise, the Interest packet is marked as pending in the receiving node and forwarded to a second CCN node in the network based on the Interest. After receiving the content from the second CCN node in response to the forwarded Interest packet, the first CCN node un-marks the Interest packet as pending and sends the content to the Interest packet requesting node.
A CCN node routes a packet based on the action corresponding to the condition as specified in its routing policy.
A CCN node comprises a routing table containing three main structures: a database called FIB (Forwarding Information Base), a buffer memory called ContentStore, and a second database called PIT (Pending Interest Table).
The FIB is used to forward Interest packets toward nodes being potential sources of matching data. The ContentStore is similar as the buffer memory of an IP router. The PIT is used to keep track of Interest packets that have been forwarded upstream toward nodes being content sources so that returned Data packets can be sent downstream to a requesting entity or node.
A user device can ask for content by broadcasting an Interest packet. A node receiving the Interest packet and having data that satisfies it can respond with a Data packet containing data related to the content. Data packet is transmitted only in response to an Interest packet.
The current dominant architectures of M2M system are known as Zigbee, Z-Wave, Wavenis, 6LoWPAN and Web of Things (Constrained Application Protocol CoAP).
ZigBee is a specification for a suite of high level communication protocols using small, low-power digital radios based on the IEEE 802.15.4-2003 standard for Low-Rate Wireless Personal Area Networks (LR-WPANs), such as wireless light switches with lamps, electrical meters with in-home-displays, consumer electronics equipment via short-range radio needing low rates of data transfer.
The protocol stack in ZigBee consists of four main layers: the PHYsical layer (PHY), the Medium Access Control (MAC) layer, the network layer (NWK), and the application layer (APL). In addition, ZigBee provides security functionality across layers. The two lower layers (PHY for physical and MAC for Medium Access Control) of the ZigBee protocol stack are defined by the IEEE 802.15.4 standard, while the rest of the stack is defined by the ZigBee specification.
The ZigBee NWK layer specifically supports addressing and routing for the tree and mesh topologies. Its functionalities involve the address assignment to facilitate multi-hop data delivery. A set of mechanisms based on the ad hoc on-demand distance vector (AODV) routing protocol is used for arbitrary point-to-point traffic.
There are two relevant ZigBee application profiles defined for the operation of APL layer. The first one is the ZigBee Home Automation Public Application Profile, which defines device descriptions, commands, attributes, and other standard practices for ZigBee applications in a residential or light commercial environment. The second one is the ZigBee Smart Energy Profile, which focuses on energy demand response and load management applications. This profile is used for communications between home devices and the energy service portal (ESP) that connects a ZigBee Smart Energy network with the communication network of an energy supply company.
Z-Wave is a wireless protocol architecture promoted by the Z-Wave Alliance for automation in residential and light commercial environments. Its main purpose is to allow reliable transmission of short messages from a control unit to one or more nodes in the network. The protocol stack in Z-Wave is composed of five main layers: the PHY, MAC, transfer, routing, and application layers.
The Z-Wave radio mainly operates in the 900 MHz ISM bands and recently supports the 2.4 GHz band. Its MAC layer defines a collision avoidance mechanism that allows the transmission of a frame when the channel is available. The Z-Wave routing layer performs routing based on a source routing approach. The application layer in Z-Wave offers the dedicated APIs for the application development.
Wavenis is a wireless protocol stack developed by Coronis Systems for control and monitoring applications in several environments, including home and building automation. Wavenis is currently being promoted and managed by the Wavenis Open Standard Alliance (Wavenis-OSA). It defines the functionality of physical, link, and network layers. Wavenis services can be accessed from upper layers through an Application Programming Interface (API).
Wavenis operates mainly in the 433 MHz, 868 MHz, and 915 MHz bands, while some products also operate in the 2.4 GHz band. The Wavenis MAC sublayer offers synchronized and non-synchronized schemes where mixed CSMA/time-division multiple access and CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) is exploited respectively. The Wavenis logical link control (LLC) sublayer manages flow and error control by offering per-frame or per-window acknowledgments ACKs.
The Wavenis network layer specifies a four-level virtual hierarchical tree. The root of the tree may play the role of a data collection sink or a gateway. A device that joins a Wavenis network intends to find an adequate parent.
An IP-based solution aims at implementing the current TCP/IP protocol stack within low cost sensors, which are nodes of the CCN storing content. Its protocol stack is composed of five layers: physical layer, MAC layer, network layer, transport layer and application layer.
The physical layer and MAC layer are normally built by following IEEE 802.15.4 specification, while the network layer is based on the specifications defined by IETF IPv6 over Low-Power Wireless Personal Access Network (6LoWPAN) Working Group (WG) where the frame format and several mechanisms are devised for the transmission of IPv6 packets on top of IEEE 802.15.4 networks.
At the transport layer and application layer, the Constrained Application Protocol (CoAP) developed by IETF is introduced for the HTTP-based application. To be specific, CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. Unlike HTTP, CoAP deals with the REST interchanges asynchronously over a UDP transport with support for both unicast and multicast interactions.
However, the previously introduced existing solutions have drawbacks when used in a CCN context.
Indeed, the Zigbee defines the overall architecture integrating the components from physical layer to application layer, which may cause complicated development and expensive deployment. For instance, the realistic device on the basis of Zigbee normally needs to be equipped with two independent micro-processors one of which is for the Zigbee protocol stack implementation that has been greatly simplified (e.g. Z-stack from Texas Instruments™) and the other is responsible for the data processing oriented to the specific application. Thus, the current Zigbee device is much more complicated and less cheap for the wide usage. On the other hand, the protocol stack of Zigbee is incompatible with existing popular protocol such as TCP/IP which brings the difficulties in developing the Zigbee-based application by following the current process.
The Z-Wave and Wavenis are confronted with the same problems as Zigbee. The private APIs set the great barrier in the development following the TCP/IP principle.
In summary, the non-IP-based solutions such as Zigbee, Z-Wave and Wavenis are organized in the highly integrated way, which limits their usage in different cases. For instance, all of these solutions are unable to support the system communicating with Wi-Fi connections. In other words, these solutions are oriented to the specific physical layer using various radio technologies so that they are unsuitable for the heterogeneous environment where multiple connections based on different transmission technologies (i.e. Wi-Fi or Ethernet) are created for communication between the sensors.
Although the IP-based solution is compatible with the existing TCP/IP network, its network layer built by 6LoWPAN is only suitable for the IEEE 802.15.4 networks. On the other hand, CoAP may lead to the potential problems in terms of energy consumption, deployment flexibility and traffic load even if it can incorporate with other lower layer protocols such as Wi-Fi.
Specifically, any change in the sensor's IP address may cause a potential fault visit from the outer network because the destination IP address is essential in the communication application developed with the sockets API that is widely used in TCP/IP network. Furthermore, the automatic configuration of IP address defined in 6LoWPAN normally leads to a change in the destination IP address in the case where the sensor is renewed due to the breakdown of the previous one.
The limitation in sensor's capability is generally unmatched with the resource requirement of supporting CoAP and 6LoWPAN together that possibly amounts to relatively larger memory size and higher processing speed in the micro processor. The powerful processing unit in the sensor means a high cost for deployment.
Since the CoAP enables the sensor to act as an HTTP sever that should response to each request from the users, a sensor that provides the data to huge number of users (e.g. an air quality sensor in the public location) has to face the problem that its battery energy may be exhausted quickly due to the hosts of visiting requests from tens of thousands people.
The M2M system built with the IP-based solution can be equivalently considered as a web system with the simpler functionality. Thus, the load balance is the crucial issue for the system operation. Too many visiting requests may block the response from the sensor even if it has no energy constraints because of the sufficient supply.